System and method for authorizing a financial transaction

ABSTRACT

A method of authorizing a financial transaction involves a payment terminal receiving, from a payment card interfaced with the payment terminal, application data in response to a predetermined authorization amount provided to the payment card by the payment terminal. The application data comprises an account number uniquely associated with the payment card. The payment terminal generates an adjusted authorization amount based on the account number and from a preliminary authorization amount received at the payment terminal, provides the payment card with the adjusted authorization amount, receives a cryptogram from the payment card in response, and provides notification of authorization of a financial transaction for the adjusted authorization amount in accordance with a confirmation that the cryptogram received at the payment terminal from the payment card was generated by the payment card from the adjusted authorization amount and from a cryptographic key uniquely associated with the payment card.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority under 35 U.S.C. §119 to, and is anon-provisional of, U.S. Provisional Patent Application No. 61/875,919,filed Sep. 10, 2013, which is hereby incorporated by reference in itsentirety for all purposes. Any and all applications for which a foreignor domestic priority claim is identified in the Application Data Sheetas filed with the present application are also hereby incorporated byreference for all purposes under 37 CFR 1.57.

FIELD

This patent application relates to a system and method for authorizing afinancial transaction. In particular, this patent application describesa system and method for authorizing a financial transaction using apayment card.

BACKGROUND

A consumer might elect to use a payment terminal (e.g. point-of-sale(POS) terminal or pin-pad) and a magnetic-stripe payment card (e.g.credit card or debit card) to complete a financial transaction with amerchant (e.g. pay for a merchant's wares/services). After the consumerapproves the authorization amount, the payment terminal prompts theconsumer to interface a payment card with the payment terminal. Thepayment terminal acquires an account number from the payment card andforwards particulars of the financial transaction (e.g. authorizationamount, and account number associated) to the merchant's acquirer foronline authorization.

To encourage repeat business, a merchant might issue discount coupons topreferred consumers for redemption against the purchase price of themerchant's wares/services. This approach requires the particulars ofeach coupon to be input to the payment terminal and the payment terminalto recalculate the authorization amount, thereby lengthening the paymentprocess. Alternately, the merchant might offer its own branded paymentcard (a loyalty card) that allows consumers to collect loyalty pointswhich can be redeemed against the purchase price of the merchant'swares/services. With this latter approach, the account number is inputto the payment terminal, and the payment terminal queries a remotedatabase with the account number to determine the number of loyaltypoints available, and recalculates the authorization amount based on thenumber of loyalty points that the customer wishes to redeem, therebyagain lengthening the payment process.

SUMMARY

This patent application discloses a payment terminal and associatedmethod that dynamically adjusts the authorization amount of a financialtransaction based on the account number provided by a payment card.

In accordance with a first aspect of this disclosure, there is provideda method of authorizing a financial transaction that involves a paymentterminal receiving, from a payment card interfaced with the paymentterminal, application data in response to a predetermined authorizationamount that is provided to the payment card by the payment terminal. Theapplication data comprises an account number uniquely associated withthe payment card.

The payment terminal generates an adjusted authorization amount based onthe account number and from a preliminary authorization amount receivedat the payment terminal, provides the payment card with the adjustedauthorization amount, and receives a cryptogram from the payment card inresponse. The payment terminal provides notification of authorization ofa financial transaction for the adjusted authorization amount inaccordance with a confirmation that the cryptogram received at thepayment terminal from the payment card was generated by the payment cardfrom the adjusted authorization amount and a cryptographic key uniquelyassociated with the payment card.

In accordance with a second aspect of this disclosure, there is provideda payment terminal that includes a card interface for interfacing apayment card with the payment terminal, and a transaction processorcoupled to the card interface. The transaction processor is configuredto receive, from a payment card interfaced with the card interface,application data in response to a predetermined authorization amountprovided to the payment card by the payment terminal. The applicationdata comprises an account number uniquely associated with the paymentcard.

The transaction processor is also configured to generate an adjustedauthorization amount based on the account number and from a preliminaryauthorization amount received at the payment terminal, provide thepayment card with the adjusted authorization amount, receive acryptogram from the payment card in response, and provide notificationof authorization of a financial transaction for the adjustedauthorization amount in accordance with a confirmation that thecryptogram received at the payment terminal from the payment card wasgenerated by the payment card from the adjusted authorization amount anda cryptographic key uniquely associated with the payment card.

In one implementation, the payment terminal is configured with a rangeof issuer identification numbers, and the transaction processor isconfigured to generate the adjusted authorization amount in accordancewith a correlation between the account number and the range of issueridentification numbers.

The transaction processor may be configured to provide notification ofauthorization of the financial transaction by transmitting over apayment network a transaction authorization request for onlineauthorization of the financial transaction. The cryptogram may comprisean online cryptogram, and the transaction authorization request mayinclude the adjusted authorization amount and the online cryptogram.

The transaction processor may be configured to provide the adjustedauthorization amount by transmitting to the payment card an offlinecryptogram request for offline authorization of the financialtransaction. The cryptogram may be included in an offline certificate,and the offline cryptogram request may include the adjustedauthorization amount. The transaction processor may be configured toprovide notification of authorization of the financial transaction byconfirming that the payment card generated the offline certificate fromthe adjusted authorization amount and the cryptographic key.

The transaction processor may be configured to provide notification ofauthorization of the financial transaction by validating the paymentcard and a bearer of the payment card, and initiating the authorizationin accordance with an outcome of the validating.

The transaction processor may be configured to provide notification ofauthorization of the financial transaction by receiving a transactionauthorization from the payment network in response to the onlinetransaction authorization request. The transaction authorization mayprovide a confirmation that the payment card generated the onlinecryptogram from the adjusted authorization amount and the cryptographickey.

The transaction processor may be further configured to providenotification of authorization of the financial transaction bytransmitting the transaction authorization to the payment card, andreceiving from the payment card confirmation that an issuer of thepayment card generated the transaction authorization.

Since the payment terminal generates the adjusted authorization amountbased on the account number associated with the payment card, and thepayment card generates the cryptogram from the adjusted authorizationamount, the vendor can offer preferred customers adjustments to thepreliminary authorization amount without requiring re-configuration ofthe payment card or the card issuer server or re-introducing the paymentcard to the payment terminal.

BRIEF DESCRIPTION OF THE DRAWINGS

An exemplary payment authorization network, payment terminal, and methodfor authorizing a financial transaction will now be described, withreference to the accompanying drawings, in which:

FIG. 1 is a schematic view of the payment authorization network,depicting a payment terminal, and an payment card issuer server;

FIG. 2 is a schematic view of one of the payment terminals; and

FIGS. 3 a and 3 b together comprise an EMV message flow diagramdepicting the method for authorizing a financial transaction.

DETAILED DESCRIPTION Payment Authorization Network

FIG. 1 is a schematic view of the payment authorization network, denotedgenerally as 100. As shown, the payment authorization network 100comprises a payment terminal 200, an acquirer server 270 and a paymentcard issuer server 300, and is configured to process financialtransactions initiated by a payment cardholder at one of the paymentterminals 200. As used herein, a “financial transaction” includes“online” transactions the particulars of which the merchant requestsauthorization in real-time, and “off-line” transactions the particularsof which the merchant requests authorization at a later time, such asthe end of the business day.

The payment terminals 200 are typically deployed at a merchant'sbusiness premises, and are configured to communicate with a one of theacquirer servers 270 via a secure acquirer network 106. As non-limitingexamples, one or more of the payment terminals 200 may be implemented asan integrated point-of-sale (POS) terminal, or a pin-pad terminal thatcommunicates with respective electronic cash register (ECR).

Each acquirer server 270 is associated with a respective merchant, andis configured to communicate with the payment terminals 200 that aredeployed at each merchant premises via each merchant's acquirer network106. The acquirer servers 270 are also configured to communicate withthe issuer server(s) 300 via a payment network 108, such as VisaNet orthe Mastercard Network.

Each issuer server 300 is associated with and administered by arespective financial institution. The financial institution associatedwith the issuer server 300 issues payment cards to cardholders (orauthorizes a third party to issue the payment cards). Each issuer server300 is configured to communicate with the acquirer servers 270 via thepayment network 108, and maintains a secure accounts database thatincludes a plurality of clusters each associated with a respectivefinancial account. Each cluster typically identifies an account numberthat is uniquely associated with the payment card 210, the current valueof a transaction counter internal to the payment card 210, andcredit/deposit entries to the associated financial account. The paymentcard 210 uses an algorithm or counter to generate an unpredictabletransaction counter number for each financial transaction, and theissuer server 300 uses a corresponding algorithm to determine the nexttransaction counter number of each payment card 210.

Although the payment authorization network 100 is shown comprising onlya single payment terminal 200, a single acquirer server 270 and a singleissuer server 300, the payment authorization network 100 typicallyincludes a plurality of the payment terminals 200, a plurality of theacquirer servers 270, and a plurality of the issuer servers 300.

Payment Terminal

As shown in FIG. 2, the payment terminal 200 includes an input device202, a display device 204, and a computer processing unit 206 that iscoupled to the input device 202 and the display device 204. The paymentterminal 200 also includes a payment card interface 208 that is coupledto the computer processing unit 206 and is configured to communicatewith a payment card 210.

The input device 202 may be implemented as a keyboard, touchpad,touchscreen or other input device suitable for allowing a user of thepayment terminal 200 to input data and/or commands that may be requiredto complete the financial transaction. The display device 204 may beimplemented as a liquid crystal display (LCD) panel, cathode ray tube(CRT) display, plasma display panel, or other display device suitablefor displaying transaction information to the user.

As will be discussed in greater detail below, the payment card 210 maybe implemented as a plastic card that has a contact form factor and/or acontactless (e.g. ISO 14443 based) form factor. If the payment card 210has a contact form factor, the payment card interface 208 may comprise aphysical port (e.g. smartcard reader) that allows the payment terminal200 to communicate directly with the payment card 210. If the paymentcard 210 has a contactless form factor, the payment card interface 208may comprise a wireless interface that allows the payment terminal 200to communicate with the payment card 210 via a wireless protocol, suchas ISO 14443. Alternately, the payment card 210 may be implemented assoftware within a portable communications device, such as a smartphone,in which case the payment card interface 208 may be configured tocommunicate with the payment card 210 of the portable communicationsdevice using short-range communications protocols, such as Bluetoothand/or Near Field Communications (NFC) as examples.

The computer processing unit 206 includes a microprocessor 212 and anon-transient computer-readable medium 214. The non-transientcomputer-readable medium 214 may be provided as non-volatile electroniccomputer memory (e.g. FLASH memory) or optical or magnetic memory (e.g.compact disc, hard disk). The non-transient memory 214 may maintain aloyalty card database 216 of payment cards for which the merchant wouldlike to offer discounts. Alternately, the loyalty card database 216 maybe maintained on an ECR associated with each payment terminal 200, on aserver (not shown) that serves the payment terminals 200 on themerchant's local area network, or on the acquirer server 270.

The merchant may issue loyalty payment cards to its customers (orauthorize a payment card issuer to do so). All such loyalty paymentcards may have an Issuer Identification Number (IIN) that identifies thepayment card as a loyalty payment card issued by that merchant.Accordingly, preferably the loyalty card database 216 is configured withthe IINs of the merchant's loyalty payment cards.

The merchant may assign the same discount rate to each loyalty paymentcard. Alternately, however, the merchant may have been assigned multipleranges of IINs for its loyalty payment cards, and may prefer to assigndifferent discount rates to different loyalty payment cards based ontheir respective IIN. For example, bearers of loyalty payment cardshaving an IIN between ‘xxa’ and ‘xxb’ may be entitled a 10% discount,and bearers of loyalty payment cards having an IIN between ‘xxc’ and‘xxd’ may be assigned a 20% discount. Accordingly, preferably theloyalty card database 216 is configured with the respective discountrate associated with each IIN of the merchant's loyalty payment cards.

The non-transient memory 214 also includes computer processinginstructions stored thereon which, when accessed from the memory 214 andexecuted by the microprocessor 212, implement an operating system 218and a transaction processor 220. The operating system 218 allows thepayment terminal 200 to accept user input from the input device 202 andto control the display device 204 and the payment card interface 208.

The operation of the transaction processor 220 will be discussed ingreater detail below. However, it is sufficient at this point to notethat the transaction processor 220 is configured to receive, from apayment card 210 that is interfaced with the payment card interface 208,application data in response to a predetermined authorization amountprovided to the payment card by the payment terminal. The applicationdata comprises an account number that is uniquely associated with thepayment card 210.

The transaction processor 220 is also configured to generate an adjustedauthorization amount based on the account number and from a preliminaryauthorization amount received at the payment terminal 200, to providethe payment card 210 with the adjusted authorization amount, to receivea cryptogram from the payment card 210 in response, and to providenotification of authorization of a financial transaction for theadjusted authorization amount in accordance with a confirmation that thecryptogram received at the payment terminal 200 from the payment card210 was generated by the payment card 210 from the adjustedauthorization amount and a cryptographic key uniquely associated withthe payment card 210.

Although the transaction processor 220 is typically implemented ascomputer processing instructions, all or a portion of the functionalityof the transaction processor 220 may be implemented instead inelectronics hardware, such as a field programmable logic gate array(FPGA) or a complex programmable logic device (CPLD).

Payment Card

As discussed, the payment card 210 may have a contact form factor and/ora contactless form factor, and may be implemented as a plasticsmartcard, chip card or integrated circuit card that includes a built-inmicro-controller and protected memory. The micro-controller andprotected memory together provide a secure self-contained computingenvironment for running cryptographic (e.g. data encryption standard(DES), triple-DES, advanced encryption standard (AES)) algorithms.Preferably, the plastic payment card 210 is implemented as a EuropayMastercard Visa (EMV) payment card that authenticates financialtransactions with payment terminals 200 using the EMV standard.Alternately, the payment card 210 may be implemented in softwareexecuting on a portable communications device, such as a smart phone,that is configured to implement payment card requirements of the EMVstandard and to authenticate financial transactions with paymentterminals 200 using the EMV standard.

The payment card 210 is configured with a personal identification number(PIN), a primary account number, expiry date and may also store one ormore private cryptographic keys and corresponding public digitalcertificates. The primary account number and private cryptographickey(s) are uniquely associated with the payment card 210. Each privatecryptographic key and the public cryptographic key of the correspondingpublic digital certificate comprise an asymmetric cryptographic keypair. Each public digital certificate is signed by the payment cardissuer. The payment card 210 may also be configured with a payment cardcryptographic master key that is uniquely associated with the paymentcard 210, and a public digital certificate of the issuer of the paymentcard 210.

Where the payment card 210 is implemented as a plastic payment card, thePIN, account number, cryptographic key(s) and public certificate(s) maybe stored in the protected memory of the payment card 210 prior todelivery of the payment card 210 to the intended user. Where the paymentcard 210 is implemented in software executing on a portablecommunications device, the payment card 210 may be configured with thePIN, account number, expiry date, cryptographic key(s), and publiccertificate(s) when the payment card 210 is installed on the portablecommunications device. Alternately, instead of the PIN being stored onthe plastic payment card or in the software executing on a portablecommunications device (the “reference” PIN), the payment card 210 may beconfigured to generate the reference PIN, for example, from thecryptographic key(s) stored in the payment card 210.

Method of Authorizing a Financial Transaction

As discussed, the payment authorization network 100 implements a methodof authorizing a financial transaction. A sample embodiment of thetransaction authorizing method will be discussed with reference to FIGS.3 a and 3 b. As will be explained, in this embodiment the paymentterminal 200 receives, from the payment card 210 that is interfaced withthe payment terminal 200, application data in response to apredetermined authorization amount that is provided to the payment card210 by the payment terminal 200. The application data comprises anaccount number that is uniquely associated with the payment card 210.

The payment terminal 200 generates an adjusted authorization amountbased on the account number and from a preliminary authorization amountthat is received at the payment terminal 200, provides the payment card210 with the adjusted authorization amount, and receives a cryptogramfrom the payment card 210 in response. The payment terminal 200 providesnotification of authorization of a financial transaction for theadjusted authorization amount in accordance with a confirmation that thecryptogram received at the payment terminal 200 from the payment card210 was generated by the payment card 210 from the adjustedauthorization amount and a private cryptographic key uniquely associatedwith the payment card 210.

An example transaction authorizing method will now be discussed indetail with reference to FIGS. 3 a and 3 b. In the following example,the payment terminal 200 is configured to implement the EMV standard(subject to the method implemented by the transaction processor 220, asdiscussed above), and the payment card 210 is implemented as a plasticEMV payment card or as software (executing on a portable communicationsdevice) that is configured to implement the EMV standard.

A customer attends at a payment terminal 200 of a merchant to complete afinancial transaction (e.g. pay for wares and/or services) with themerchant. At step S300, the transaction particulars, including thepre-discounted total payable amount (preliminary authorization amount),are input into the payment terminal 200 directly by the merchant orindirectly via the ECR. The payment terminal 200 displays thepreliminary authorization amount on the display device 204, and promptsthe customer to approve the displayed authorization amount via the inputdevice 202. The customer approves the displayed authorization amount,and the payment terminal 200 prompts the customer to interface a paymentcard 210 with the payment card interface 208 of the merchant's paymentterminal 200.

After the customer (cardholder) interfaces a payment card 210 with thepayment terminal 200, the payment card 210 provides the payment terminal200 with a Processing Options Data List (PDOL), at step S302, thatidentifies the data elements that the payment card 210 will require toauthorize the financial transaction.

At step S304, the transaction processor 220 of the payment terminal 200transmits to the payment card 210 a Get Processing Options command thatincludes the data specified in the PDOL. Typically the PDOL lists theauthorization amount as one of the required data elements. Although thepayment terminal 200 was provided with the preliminary authorizationamount at step S300, the cardholder might be entitled to a discount tothe preliminary authorization amount based on the account number of thepayment card 210. Since the actual authorization amount therefore isunknown at the stage, at step S304 the transaction processor 220 setsthe authorization amount datum of the Get Processing Options command toa predetermined authorization amount. To comply with the EMV standard,preferably the predetermined authorization amount included in the GetProcessing Options is hexadecimal zero.

At step S306, the payment card 210 provides the payment terminal 200with an Application File Locator (AFL) message that identifies thelocation(s) in the protected memory of the payment card 210 of variousdata elements that the payment terminal 200 may need to authorize thefinancial transaction. At step S306, the payment card 210 also providesthe payment terminal 200 with an Application Interchange Profile (AIP)that identifies the capabilities of the payment card 210, such as thetype of offline data authentication (discussed below) that the paymentcard 210 supports.

Using the AFL, at step S308 the transaction processor 220 transmits tothe payment card 210 a Read Record command for the various data elementsrequired by the payment terminal 200. Typically, the Read Record commandrequests the account number, expiry date and software applicationversion of the payment card 210. The Read Record command may alsorequest a public digital certificate of the payment card 210 andoptionally also a public digital certificate of the issuer of thepayment card 210. The payment card 210 responds to the payment terminal200, at step S310, with the account number and any other data requestedby the Read Record command. At step S310, the payment card 210 may alsoprovide the payment terminal 200 with a Card Risk Management DataObjects List (CDOL) that identifies the data elements that the paymentcard 210 may require to generate a cryptogram.

From the expiry date and application version of the software stored onthe payment card 210 (as defined in the AIP), at step S312 the paymentterminal 200 determines whether the payment card 210 is restricted frombeing used to authorize the financial transaction.

As discussed, the payment terminal 200 may be configured with a loyaltycard database 216 (or may be in communication with a loyalty carddatabase 216 that is maintained on an ECR, on a server that serves thepayment terminals 200 on the merchant's local area network, or on theacquirer server 270) of account numbers for which the merchant wouldlike to offer discounts. Accordingly, at step S314 the transactionprocessor 220 queries the loyalty card database 216 (whether storedinternally or externally to the payment terminal 200) with the accountnumber received from the payment card 210 to determine whether thecardholder is a preferred customer and, if so, the allowed discount (ifany) to the preliminary authorization amount.

The payment terminal 200 may then validate the payment card 210 based onthe type of offline data authentication, if any, identified in the AIP(received at step S306). To do so, at step S316 the transactionprocessor 220 may transmit to the payment card 210 a GenerateApplication Cryptogram command, requesting an offline cryptogram fromthe payment card 210.

If the AIP indicates that the payment card 210 supports Dynamic DataAuthentication (DDA) or Combined Data Authentication (CDA), thetransaction processor 220 generates an unpredictable number, andincludes the unpredictable number in the offline cryptogram request. Inresponse, the payment card 210 generates an offline cryptogram from theunpredictable number and a private cryptographic key of the payment card210, and provides the payment terminal 200 with the offline cryptogram,at step S318. At step S320, the transaction processor 220 validates thepayment card 210 by using the public certificate of the payment cardissuer to validate the public certificate of the payment card 210 (bothreceived in response to the Read Record command at step S310), and usesthe public certificate of the payment card 210 to verify that thepayment card 210 generated the offline cryptogram.

If the AIP indicates that the payment card 210 does not support DDA orCDA, but instead supports Static Data Authentication (SDA), the paymentterminal 200 receives from the payment card 210 (in response to the ReadRecord command at step S310) signed static application data that isstored on the payment card. The transaction processor 220 validates thepayment card 210, at step S320, by using the public certificate of thepayment card issuer to verify that the payment card issuer signed thestatic application data.

The payment terminal 200 may then authenticate the bearer of the paymentcard 210 by prompting the customer (cardholder) to input a PIN into thepayment terminal 200 via the input device 202. After the customer(cardholder) inputs a PIN into the payment terminal 200, at step S322the transaction processor 220 transmits to the payment card 210 a Verifycommand that includes the PIN. The payment card 210 uses the referencePIN that is stored in the protected memory of the payment card 210 (orgenerates the reference PIN) to validate the PIN received from thepayment terminal 200, and responds to the payment terminal 200 with apass/fail validation message, at step S324, indicating whethervalidation of the PIN received from the payment terminal 200 passed orfailed.

At step S326, the transaction processor 220 assesses the risk associatedwith the financial transaction by comparing the adjusted/preliminaryauthorization amount against a floor limit established by the issuer ofthe payment card 210.

Although the financial transaction authorizing method has been describedthus far as comprising the sequence of processing restrictions (stepS312), payment card validation (steps S316 to S320), cardholderauthentication (steps S322 to S324) and risk management (step S326), themethod is not limited to this particular sequence. The financialtransaction authorizing method may be effected by implementing theprocessing restrictions, payment card validation, cardholderauthentication and risk management stages in any order.

Based on the results of the processing restrictions, payment cardvalidation, cardholder authentication and transaction floor limit check(collectively the Terminal Verification Results), at step S328 thetransaction processor 220 determines whether the financial transactionshould be approved online, approved offline, or declined offline.

If the transaction processor 220 determines, at step S328, that thefinancial transaction can be approved offline, at step S330 thetransaction processor 220 transmits to the payment card 210 a GenerateApplication Cryptogram command, requesting an offline TransactionCertificate (TC) from the payment card 210. Typically, the CDOL(received from the payment card 210 at step S310) lists theauthorization amount as one of the data elements required by the paymentcard 210 to generate a cryptogram. Therefore, if the account number ofthe payment card 210 correlates with one of the IIN ranges stored in theloyalty card database 216, the transaction processor 220 generates anadjusted authorization amount by discounting the preliminaryauthorization amount by the discount rate that is associated with theIIN range in the loyalty card database 216. The transaction processor220 generates an unpredictable number and incorporates the adjustedauthorization amount and the unpredictable number into the GenerateApplication Cryptogram command. Alternately, where the account numberdoes not correlate with one of the IIN ranges stored in the loyalty carddatabase 216, the transaction processor 220 incorporates the preliminaryauthorization amount and the unpredictable number into the GenerateApplication Cryptogram command.

At step S332, the payment card 210 determines whether the transactioncan be approved offline, for example, by verifying that the number ofconsecutive transactions previously approved offline has not exceeded apredetermined limit.

If the payment card 210 determines, at step S332, that the transactioncan be approved offline, the payment card 210 generates an offlinecertificate TC from a cryptographic key of the payment card 210 and froma message authentication code that is generated from the TerminalVerification Results, the adjusted/preliminary authorization amount andunpredictable number received from the payment terminal 200, thetransaction date, the account number and a transaction counter internalto the payment card 210. The payment card 210 may generate the offlinecertificate TC by (i) generating a cryptographic session key from thepayment card cryptographic master key and the transaction counter, (ii)applying the Terminal Verification Results, adjusted/preliminaryauthorization amount, unpredictable number, transaction date, accountnumber and transaction counter and the session key as inputs to acryptographic algorithm, (iii) signing the resulting offline cryptogramwith a private cryptographic key of the payment card 210, and (iv)incorporating the offline cryptogram into the offline certificate TC.Since the cryptographic session key is generated from the payment cardcryptographic master key and the transaction counter, the cryptographicsession key is uniquely associated with the payment card 210.

The payment card 210 responds to the payment terminal 200 with theoffline certificate TC, at step S352. The payment terminal 200 uses thepublic certificate of the payment card 210 to confirm that the paymentcard 210 generated the offline cryptogram (and the offline certificateTC) from the adjusted/preliminary authorization amount and thereforethat the payment card 210 authorized the transaction. The paymentterminal 200 then provides a notification, on the display device 204,advising the customer that the financial transaction was authorized.

If the transaction processor 220 determines, at step S328, that thefinancial transaction should be approved online, at step S330 thetransaction processor 220 transmits to the payment card 210 a GenerateApplication Cryptogram command, requesting an online cryptogram from thepayment card 210. The transaction processor 220 generates anunpredictable number and incorporates the adjusted/preliminaryauthorization amount and the unpredictable number into the GenerateApplication Cryptogram command.

Upon receipt of the online cryptogram request (or if the transactionprocessor 220 requested an offline certificate TC at step S330, but thepayment card 210 determined, at step S332, that the transaction shouldnot be approved offline), the payment card 210 generates an onlineApplication Request Cryptogram (ARQC) from a cryptographic key of thepayment card 210 and from a message authentication code that isgenerated from the Terminal Verification Results, theadjusted/preliminary authorization amount and unpredictable numberreceived from the payment terminal 200, the transaction date, theaccount number and the payment card internal transaction counter. Thepayment card 210 may generate the online cryptogram ARQC by (i)generating a cryptographic session key from the payment cardcryptographic master key and the transaction counter, and (ii) applyingthe Terminal Verification Results, adjusted/preliminary authorizationamount, unpredictable number, transaction date, account number andtransaction counter (collectively the Issuer Authorization Data) and thesession key as inputs to a cryptographic algorithm.

Since the cryptographic session key is generated from the payment cardcryptographic master key and the transaction counter, the cryptographicsession key is uniquely associated with the payment card 210. Thepayment card 210 responds to the payment terminal 200 with the onlinecryptogram ARQC, at step S334.

At step S336, the transaction processor 220 generates an AuthorizationRequest Message that includes the Issuer Authorization Data and theonline cryptogram ARQC, and forwards the Authorization Request Messageto the acquirer server 270 via the acquirer network 106. At step S338,the acquirer server 270 directs the Authorization Request Message to theissuer server 300, over the payment network 108, for validation.

At step S340, the issuer server 300 verifies that the payment card 210generated the online cryptogram ARQC. To do so, the issuer server 300may (i) recover the payment card's session key by applying the accountnumber, payment card internal transaction counter and a card issuercryptographic master key as inputs to a suitable cryptographicalgorithm, (ii) decrypt the online cryptogram ARQC with the recoveredsession key, (iii) compute a message authentication code from the IssuerAuthorization Data, and (iv) compare the computed message authenticationcode against the decrypted cryptogram.

At step S340, the issuer server 300 also applies its prevailing riskmanagement rules to the adjusted/preliminary authorization amount.Therefore, for example, the issuer server 300 may determine whether thefinancial account that is associated with the account number is stillactive and has sufficient credit/funds to complete the transaction (i.e.the adjusted/preliminary authorization amount is less than thecredit/funds balance for the account). The issuer server 300 may alsodetermine whether the transaction is consistent with the cardholder'shistory of transactions.

The issuer server 300 generates an authorization response code thatindicates the outcome of the risk management analysis and the onlinecryptogram ARQC verification (i.e. whether the issuer approved ordeclined the transaction and whether the payment card 210 generated theonline cryptogram ARQC from the adjusted/preliminary authorizationamount and the cryptographic master key (session key) of the paymentcard 210), and generates an Application Response Cryptogram (ARPC) froma cryptographic key of the payment card 210 and from a messageauthentication code that is generated from the account number,authorization response code and online cryptogram ARQC. The issuerserver 300 may generate the cryptogram ARPC by applying theauthorization response code, online cryptogram ARQC and session key(recovered from the account number and the card issuer cryptographicmaster key) as inputs to a suitable cryptographic algorithm.

At step S342, the issuer server 300 generates an Authorization ResponseMessage that includes the Issuer Authorization Data, authorizationresponse code and cryptogram ARPC, and directs the AuthorizationResponse Message to the acquirer server 270 via the payment network 108.At step S344, the acquirer server 270 forwards the AuthorizationResponse Message to the payment terminal 200, via the acquirer network106.

At step S346, the payment terminal 200 examines the authorizationresponse code of the Authorization Response Message. If theauthorization response code indicates that the card issuer authorizedthe transaction and that the payment card 210 generated the onlinecryptogram ARQC from the adjusted/preliminary authorization amount andthe cryptographic master key (or session key) of the payment card 210,at step S348 the transaction processor 220 transmits to the payment card210 a Generate Application Cryptogram command, requesting from thepayment card 210 a Transaction Certificate (TC) confirming that theissuer server 300 generated the Authorization Response Message. Thetransaction processor 220 generates an unpredictable number andincorporates the Issuer Authorization Data and unpredictable number,authorization response code and cryptogram ARPC into the GenerateApplication Cryptogram command.

At step S350, the payment card 210 then determines whether the issuerserver 300 generated the cryptogram ARPC. To do so, the payment card 210may (i) decrypt the cryptogram ARPC with the payment card's session key,(ii) compute a message authentication code from the account number,authorization response code and online cryptogram ARQC, and (iii)compare the computed message authentication code against the decryptedcryptogram.

If the payment card 210 confirms that the issuer server 300 generatedthe cryptogram ARPC and therefore that the card issuer authorized thetransaction, the payment card 210 generates the certificate TC from acryptographic key of the payment card 210 and from a messageauthentication code that is generated from the Terminal VerificationResults, the adjusted/preliminary authorization amount and unpredictablenumber received from the payment terminal 200, the transaction date, theaccount number and the internal transaction counter. The payment card210 may generate the certificate TC by (i) generating a session key fromthe payment card cryptographic master key and the transaction counter,(ii) applying the Terminal Verification Results, adjusted/preliminaryauthorization amount, unpredictable number, transaction date, accountnumber and transaction counter and the session key as inputs to acryptographic algorithm, (iii) signing the resulting cryptogram with aprivate cryptographic key of the payment card 210, and (iv)incorporating the cryptogram into the certificate TC. Since thecryptographic session key is generated from the payment cardcryptographic master key and the transaction counter, the cryptographicsession key is uniquely associated with the payment card 210.

The payment card 210 responds to the payment terminal 200 with thecertificate TC, at step S352. The payment terminal 200 uses the publiccertificate of the payment card 210 to confirm that the payment card 210generated the cryptogram (and the certificate TC) from theadjusted/preliminary authorization amount and therefore that the issuerserver 300 authorized the transaction. The payment terminal 200 thenprovides a notification, on the display device 204, advising thecustomer that the financial transaction was authorized.

If the authorization response code indicates that the card issuerdeclined the transaction (or if, at step S328, the transaction processor220 determined that the transaction should be declined offline), at stepS348 the transaction processor 220 transmits to the payment card 210 aGenerate Application Cryptogram command, requesting from the paymentcard 210 an Application Authentication Cryptogram (AAC) confirming thatthe issuer server 300 generated the Authorization Response Message. Thetransaction processor 220 generates an unpredictable number andincorporates the Issuer Authorization Data and unpredictable number intothe Generate Application Cryptogram command.

The payment card 210 generates the cryptogram AAC from a cryptographickey of the payment card 210 and from a message authentication code thatis generated from the Terminal Verification Results, theadjusted/preliminary authorization amount and unpredictable numberreceived from the payment terminal 200, the transaction date, theaccount number and the internal transaction counter. The payment card210 may sign the resulting cryptogram with a private cryptographic keyof the payment card 210.

The payment card 210 responds to the payment terminal 200 with thecryptogram AAC, at step S352. The payment terminal 200 uses the publiccertificate of the payment card 210 to confirm that the payment card 210generated the cryptogram AAC from the adjusted/preliminary authorizationamount and therefore that the payment card 210 or the issuer server 300declined the transaction. The payment terminal 200 then provides anotification, on the display device 204, advising the customer that thefinancial transaction was declined.

As will be apparent, therefore, based on the type of cryptogram receivedat the payment terminal 200, the payment terminal 200 provides anotification advising whether the financial transaction was authorizedor declined. Since the payment terminal 200 generates the adjustedauthorization amount based on the account number associated with thepayment card 210, and the payment card 210 generates the online oroffline cryptogram from the adjusted authorization amount, the merchantcan offer preferred customers adjustments to the preliminaryauthorization amount without requiring re-configuration of the paymentcard 210 or the card issuer server 300.

1. A method of authorizing a financial transaction comprising: a paymentterminal receiving, from a payment card interfaced with the paymentterminal, application data in response to a predetermined authorizationamount provided to the payment card by the payment terminal, theapplication data comprising an account number uniquely associated withthe payment card; the payment terminal generating an adjustedauthorization amount based on the account number and from a preliminaryauthorization amount received at the payment terminal; the paymentterminal providing the payment card with the adjusted authorizationamount, and receiving a cryptogram from the payment card in response;and the payment terminal providing notification of authorization of afinancial transaction for the adjusted authorization amount inaccordance with a confirmation that the cryptogram received at thepayment terminal from the payment card was generated by the payment cardfrom the adjusted authorization amount and a cryptographic key uniquelyassociated with the payment card.
 2. The method according to claim 1,wherein the payment terminal is configured with a range of issueridentification numbers, and the generating an adjusted authorizationamount comprises the payment terminal generating the adjustedauthorization amount in accordance with a correlation between theaccount number and the range of issuer identification numbers.
 3. Themethod according to claim 2, wherein the cryptogram comprises an onlinecryptogram, and the providing notification of authorization of afinancial transaction comprises the payment terminal transmitting over apayment network a transaction authorization request for onlineauthorization of the financial transaction, the transactionauthorization request including the adjusted authorization amount andthe online cryptogram.
 4. The method according to claim 2, wherein thecryptogram is included in an offline certificate, the providing theadjusted authorization amount comprises the payment terminaltransmitting to the payment card an offline cryptogram request foroffline authorization of the financial transaction, the offlinecryptogram request including the adjusted authorization amount, and theproviding notification of authorization of a financial transactioncomprises the payment terminal confirming that the payment cardgenerated the offline certificate from the adjusted authorization amountand the cryptographic key.
 5. The method according to claim 1, whereinthe providing notification of authorization of a financial transactioncomprises the payment terminal validating the payment card and a bearerof the payment card, and initiating the authorization in accordance withan outcome of the validating.
 6. The method according to claim 5,wherein the card bearer validating comprises the payment terminaltransmitting a personal identification number to the payment card, andreceiving from the payment card a validation of the personalidentification number.
 7. The method according to claim 3, wherein theproviding notification of authorization of a financial transactioncomprises the payment terminal receiving a transaction authorizationfrom the payment network in response to the online transactionauthorization request, the transaction authorization providing aconfirmation of the payment card generating the online cryptogram fromthe adjusted authorization amount and the cryptographic key.
 8. Themethod according to claim 7, wherein the providing notification ofauthorization of a financial transaction comprises the payment terminaltransmitting the transaction authorization to the payment card, andreceiving from the payment card confirmation that an issuer of thepayment card generated the transaction authorization.
 9. The methodaccording to claim 1, wherein the cryptogram comprises an onlinecryptogram, and the providing the adjusted authorization amountcomprises the payment terminal transmitting to the payment card acryptogram request requesting the online cryptogram from the paymentcard, the cryptogram request including the adjusted authorizationamount.
 10. The method according to claim 1, wherein the paymentterminal receives the preliminary authorization amount from anelectronic cash register.
 11. A computer-readable medium comprisingcomputer processing instructions stored thereon for execution by apayment terminal, the computer processing instructions, when executed bythe payment terminal, causing the payment terminal to perform the methodof claim
 1. 12. A payment terminal comprising: a card interface forinterfacing a payment card interfaced with the payment terminal; and atransaction processor coupled to the card interface, the transactionprocessor being configured to: (i) receive, from a payment cardinterfaced with the card interface, application data in response to apredetermined authorization amount provided to the payment card by thepayment terminal, the application data comprising an account numberuniquely associated with the payment card; (ii) generate an adjustedauthorization amount based on the account number and from a preliminaryauthorization amount received at the payment terminal, provide thepayment card with the adjusted authorization amount, and receive acryptogram from the payment card in response; and (iii) providenotification of authorization of a financial transaction for theadjusted authorization amount in accordance with a confirmation that thecryptogram received at the payment terminal from the payment card wasgenerated by the payment card from the adjusted authorization amount anda cryptographic key uniquely associated with the payment card.
 13. Thepayment terminal according to claim 12, wherein the payment terminal isconfigured with a range of issuer identification numbers, and thetransaction processor is configured to generate the adjustedauthorization amount in accordance with a correlation between theaccount number and the range of issuer identification numbers.
 14. Thepayment terminal according to claim 13, wherein the cryptogram comprisesan online cryptogram, and the transaction processor is configured toprovide notification of authorization of a financial transaction bytransmitting over a payment network a transaction authorization requestfor online authorization of the financial transaction, the transactionauthorization request including the adjusted authorization amount andthe online cryptogram.
 15. The payment terminal according to claim 13,wherein the cryptogram is included in an offline certificate, thetransaction processor is configured to provide the adjustedauthorization amount by transmitting to the payment card an offlinecryptogram request for offline authorization of the financialtransaction, the offline cryptogram request including the adjustedauthorization amount, and the transaction processor is configured toprovide notification of authorization of a financial transaction byconfirming that the payment card generated the offline certificate fromthe adjusted authorization amount and the cryptographic key.
 16. Thepayment terminal according to claim 12, wherein the transactionprocessor is configured to provide notification of authorization of afinancial transaction by validating the payment card and a bearer of thepayment card, and initiating the authorization in accordance with anoutcome of the validating.
 17. The payment terminal according to claim16, wherein the transaction processor is configured to authenticate thebearer of the payment card by transmitting a personal identificationnumber to the payment card, and receiving from the payment card avalidation of the personal identification number.
 18. The paymentterminal according to claim 14, wherein the transaction processor isconfigured to provide notification of authorization of a financialtransaction by receiving a transaction authorization from the paymentnetwork in response to the online transaction authorization request, thetransaction authorization providing a confirmation of the payment cardgenerating the online cryptogram from the adjusted authorization amountand the cryptographic key.
 19. The payment terminal according to claim18, wherein the transaction processor is configured to providenotification of authorization of a financial transaction by transmittingthe transaction authorization to the payment card, and receiving fromthe payment card confirmation that an issuer of the payment cardgenerated the transaction authorization.
 20. A method of authorizing afinancial transaction comprising: a payment terminal receiving, from apayment card interfaced with the payment terminal, application data inresponse to a predetermined authorization amount provided to the paymentcard by the payment terminal, the application data comprising an accountnumber uniquely associated with the payment card; the payment terminalgenerating an adjusted authorization amount based on the account numberand from a preliminary authorization amount received at the paymentterminal, and transmitting to the payment card a cryptogram requestrequesting an online cryptogram from the payment card, the cryptogramrequest including the adjusted authorization amount; the paymentterminal receiving the online cryptogram from the payment card inresponse to the cryptogram request, and transmitting over a paymentnetwork a payment authorization request for online authorization of afinancial transaction for the adjusted authorization amount, the paymentauthorization request including the online cryptogram; and the paymentterminal receiving a transaction authorization from the payment networkin response to the payment authorization request, the transactionauthorization providing a confirmation of the payment card generatingthe online cryptogram from the adjusted authorization amount and acryptographic key uniquely associated with the payment card.